Multiple System Operators (MSOs) are converging their video and data content-delivery networks (CDNs) to an all-digital converged network, allowing advanced services to be deployed, such as video on demand (VoD), switched digital video, on-line gaming and network based personal video recording (PVR) services. The ability to converge networks is due, in large part, to the OpenCable initiative for standardizing the operating systems of electronics that connect to the network, such as set top boxes (STBs), so that they could interact with the different CDNs. For STBs and video related services specifically, CableLabs®, a standards organization in the cable industry, published the OpenCable™ Applications Platform (OCAP), which addressed the problem of proprietary operating system software, and created a common platform on which interactive services may be deployed. OCAP has been adopted by the major MSOs and has been branded the Tru2way® specification.
As part of Tru2way specification, key changes were implemented that affect the command and control transport mechanism between the STB and the headend.
Specifically, CableLabs laid the groundwork for new interactive video services when it developed the DOCSIS Set-top Gateway (DSG) Interface Specification, which leverages DOCSIS standards-based equipment and introduces open, standards-based technology for video networks. This specification defines interface requirements for transport of a class of service known as “out-of-band (OOB) messaging” between network controllers, application servers, and customer premises equipment (CPE) such as residential gateways, televisions and STBs.
Prior to Tru2way standard, core STB technology remained primarily proprietary in nature. STB technology relied on the use of a dedicated “out-of band” or OOB channel to transmit control messaging from the headend to each STB. For example, conditional access (CA), system information (SI), electronic program guide (EPG), emergency alert system (EAS) and other STB command and control messages were sent via a downstream OOB radio frequency (RF) channel that was separate from the channels actually being watched. Specifically, an OOB gateway in the headend system received the content for the OOB channel over an IP/Ethernet connection from an application server, terminated the IP/Ethernet connection, and converted the content to ATM or MPEG-TS frames before passing the content down the OOB channel to the STB. Each OOB carrier typically required unique, proprietary headend equipment such as out-of-band modulators and return path demodulators.
Applicants identified a number of problems associated with a proprietary OOB channel. Besides requiring proprietary headend equipment to transmit/receive the signal as mentioned above, the proprietary nature of the OOB signal rendered it opaque and not subject to inspection and testing. Consequently, problems were usually realized only after a subscriber called to complain about service. Furthermore, even if one were able to penetrate the proprietary nature of the OOB signal and decode it, monitoring all the OOB signals across different plants was impractical because of all the different types of OOB signals used and the lack of connectivity between headends.
The DSG specification, however, moves away from traditional proprietary OOB transport to widespread, IP-based technology, while preserving the essential nature of current OOB transport. The control information is carried on an “always-on” control channel that is separate from the video delivery channel. Furthermore, DSG consolidates control traffic from the legacy video network onto the Converged Regional Area Network (CRAN) and DOCSIS networks. Applicant has identified that that this interoperability and consolidation of control traffic offers unique opportunities to monitor and test control channel signals.